¿Cómo trabajar con las soluciones de streaming en Kafka?

Actualmente, las compañías necesitan cumplir con unos ambiciosos requisitos de negocio para mantenerse competitivas en el mercado. Por ello, ha surgido una gran demanda de soluciones para el procesamiento de grandes flujos de datos en tiempo real. Y en este panorama tecnológico se encuentra Kafka, una plataforma distribuida de transmisión de datos.

Ya os hemos contado algunas características fundamentales de Kafka y una pequeña introducción teórica a la biblioteca de Kafka Streams.

También hemos hablado en este podcast sobre stream processing, con el objetivo de entender este ecosistema y mostrar una forma de simplificar la creación de aplicaciones que requieran de procesar y operar sobre distintos flujos de datos de una forma rápida y escalable.

Estos artículos os servirán de punto de partida para comprender todo lo que se va a mostrar más adelante.

Para ampliar el conocimiento de esta herramienta, vamos a publicar una serie de posts sobre la implementación de soluciones para el procesamiento de flujos de datos en tiempo real sobre Kafka.

Para ello, no solo nos vamos a centrar en conceptos teóricos, sino que también vamos a trabajar sobre un caso de uso en particular: la detección de fraude de movimientos de tarjetas bancarias.

El objetivo es resolver este caso implementando diferentes soluciones para el procesamiento de flujos de datos con distintas tecnologías propias del ecosistema Kafka, como pueden ser Kafka Streams, Kafka Streams (Processor API) y ksqlDB, mostrando cómo trabajar con estas tecnologías y sus puntos más relevantes.

Finalmente, compararemos todas las soluciones implementadas con las distintas tecnologías atacando distintos puntos interesantes que puedan ayudarnos a elegir la opción que más se adecúe a lo que necesitamos dependiendo de la situación en la que nos encontremos.

Presentando el caso de uso: detección de fraude en tiempo real

Vamos a situarnos en un escenario imaginario, el cual se asemeja bastante a lo que se puede ver en un caso real.

El objetivo de los artículos no es definir una estrategia de detección de fraude, sino mostrar cómo, utilizando diferentes tecnologías para el procesamiento de flujos de eventos sobre Kafka, podemos detectar ciertos comportamientos en tiempo real que posibiliten una posterior toma de decisiones de forma rápida y eficaz.

Una entidad bancaria maneja una cantidad de movimientos muy grande debido a las operaciones que los clientes realizan constantemente con sus tarjetas de crédito desde distintas fuentes. Por ello, uno de los aspectos más importantes para esta organización es la de prevenir las operaciones fraudulentas que pueden hacerse con dichas tarjetas, ya que la confianza de los clientes es crucial para la entidad.

En la situación actual, dicha entidad tiene ya diseñadas unas reglas e implementado un proceso para detectar el fraude a través de los movimientos de las tarjetas. Este proceso consiste en un proceso batch, es decir, cada cierto tiempo recoge los datos de diferentes fuentes de información, los analiza y genera una serie de casos de fraude para ser analizados en detalle por parte de la entidad.

Entonces, si el proceso funciona correctamente, ¿cuál es el problema?

Pues bien, desde la parte analítica se alerta sobre que el proceso actual de control de fraude ha quedado obsoleto, ya que con las posibilidades que ofrece la tecnología actualmente, se podría abordar la necesidad existente de acortar los tiempos de detección de fraude para poder reaccionar a tiempo y controlar todas las operaciones fraudulentas que se pueden dar.

El objetivo es implementar un nuevo proceso que, en vez de ejecutarse cada cierto tiempo (batch), sea capaz de procesar y evaluar los movimientos de las tarjetas que se produzcan en tiempo real.

De esta manera, vamos a ser capaces de detectar los movimientos de fraude en tiempo real, o, por lo menos, cercano a tiempo real, y ser capaces de tomar las medidas necesarias de forma rápida y eficiente, a fin de salvaguardar el negocio y tener clientes satisfechos.

Para simplificar el caso de uso y mejorar su entendimiento, vamos a tratar un número limitado de casos de fraude inventados que sirvan como ejemplo para verificar cómo funcionan las tecnologías que usaremos para implementar dicho caso. Nos vamos a centrar en:

• Movimientos de retirada de dinero en cajeros o pagos en establecimientos físicos: analizamos si se utiliza la misma tarjeta para sacar dinero en cajeros automáticos diferentes o realizar pagos en establecimientos físicos diferentes en un período determinado de tiempo. Se considera fraude potencial debido a que una persona no puede estar en dos sitios a la vez.
  También se considera fraude potencial que una misma tarjeta sea empleada en múltiples movimientos consecutivos, independientemente de que sea en el mismo cajero o establecimiento o en diferentes.
• Compras online consecutivas superando un límite establecido: analizamos si se usa la misma tarjeta para comprar en varios sitios online en un período de tiempo, superando una cantidad total definida. Se considera fraude potencial porque no es habitual realizar varias compras online en un periodo de tiempo tan pequeño.

Una vez detectados los movimientos de fraude, estos podrían ser analizados por otros sistemas automáticos o manuales para confirmar o desestimar el fraude.

Durante esta serie de artículos simplemente vamos a detectar los escenarios, dejando los mensajes asociados en un topic de Kafka para que puedan ser tratados.

Diseñando la solución a alto nivel

Como hemos comentado anteriormente, el objetivo es implementar un proceso que mejore la detección de operaciones fraudulentas de las tarjetas, pasando de un procesamiento batch a un procesamiento en tiempo real, o al menos cerca de tiempo real.

Es importante mencionar que todo lo que haya construido alrededor del proceso de detección de fraude, como pueden ser distintas herramientas de acciones a tomar a posteriori o los almacenes de movimientos correspondientes a cada una de las fuentes, van a seguir usándose de la misma manera, intentando implementar una solución tenga un mínimo impacto en los sistemas actuales.

Teniendo en cuenta esto, diseñamos una solución para cumplir con los objetivos marcados.

Se puede observar que la nueva solución añade algunos elementos respecto a la actual solución en batch.

• Una herramienta de mensajería y procesado de eventos como lo que proporciona el ecosistema Kafka.
• Una herramienta de CDC para llevar a un topic de Kafka los datos de los movimientos de tarjetas de las distintas fuentes y, de esta forma, no tener que modificar los servicios que lo soportan.
• Un nuevo componente, fraud process, que contendrá la lógica asociada a la detección de los escenarios de fraude que hemos comentado anteriormente y que publicará los casos en otro topic de Kafka.

Durante el desarrollo de los artículos de la serie, no vamos a centrarnos en construir la herramienta CDC ni otras partes no relevantes, sino vamos a centrarnos en el componente fraud process, ofreciendo diferentes formas de implementarlo.

No obstante, si necesitas más información sobre CDC y algunas alternativas, puedes consultar también estos artículos del blog de Paradigma:

• CDC con Debezium
• CDC con Oracle Golden Gate
• CDC con Confluent

Ahora bien, ¿qué tecnologías vamos a usar para implementar este proceso? Nos vamos a centrar en Kafka Streams, tanto DSL y Processor API, y en ksqlDB.

Manos a la obra

Una vez conocido el caso de uso, los problemas que se tienen y la solución planteada, no esperamos más para implementar cada una de las soluciones propuestas y poder sacar distintas conclusiones.

Para ello, cada uno de los artículos van a centrarse en mostrar tanto la parte teórica como los detalles más relevantes de la implementación de cada solución, adjuntando los repositorios de código para poder ejecutarlo en un entorno local y poder jugar con ello de forma rápida. Aquí podéis encontrar los artículos de esta serie:

• Stream processing con Kafka Streams DSL.
• Stream processing con Kafka Streams Processor API.
• Stream processing con ksqlDB.
• ¿Y si ksqlDB nos permitiese hacer Change Data Capture?

¡Esperamos que os guste el contenido!